-
Notifications
You must be signed in to change notification settings - Fork 123
Support UNIX Domain Sockets #151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support UNIX Domain Sockets #151
Conversation
Can one of the admins verify this patch? |
2 similar comments
Can one of the admins verify this patch? |
Can one of the admins verify this patch? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this patch!
I don't think we should use file://
as the scheme for Unix domain sockets: file://
is a very well-understood scheme from the perspective of browser user agents, and overloading that semantic here for another purpose seems unwise. I think the traditional choice for a scheme for Unix sockets is unix://
, which works better. We could also choose to use unix+http://
, but I think I'd begin with unix://
for now: we can always widen the list.
|
||
struct RedirectState { | ||
var count: Int | ||
var visited: Set<URL>? | ||
} | ||
|
||
var redirectState: RedirectState? | ||
private var value: HTTPRequest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't love using a protocol existential here. I think the splitting of basic request types is a good idea, but I'd rather use an enumeration that we can switch over than the protocol existential.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems the only difference between implementations is how they handle scheme? Why not just add a unix://
to a list of supported schemes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just add a unix:// to a list of supported schemes?
slightly different asserts in Request constructor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two questions:
|
My use case is local Docker server over unix socket |
Point 2 would probably not be useful since we running it on the same machine... |
in general yes. I don't know if nio can handle it though. Looks like eg. postgres can utilise that |
You can run TLS over the unix socket, it's mostly not useful though it can be if the process on the other side of the unix socket is a TCP proxy. It's worth keeping it as a thing we could potentially support in future.
NIO's TLS implementation is 100% composable, so it can be run over literally any stream transport. 😉 |
self.kind = .unixSocket | ||
self.host = "" | ||
} else { | ||
throw HTTPClientError.unsupportedScheme(scheme) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This block can be rewritten to be substantially cleaner by defining some helpers:
extension Kind {
private static var hostSchemes = ["http", "https"]
private static var unixSchemes = ["unix"]
init(forScheme scheme: String) throws {
if Kind.hostSchemes.contains(scheme) {
self = .host
} else if Kind.unixSchemes.contains(scheme) {
self = .unixSocket
} else {
throw HTTPClientError.unsupportedScheme
}
}
func hostFromURL(_ url: URL) throws -> String {
switch self {
case .host:
guard let host = url.host else {
throw HTTPClientError.emptyHost
}
return host
case .unixSocket:
return ""
}
}
}
This code then becomes:
self.kind = try Kind(scheme: scheme)
self.host = try self.kind.hostFromURL(url)
We can then also rewrite kind.isSchemeSupported
in terms of our statics. This should put most of the complexity into the enum definition, which helps keep the code elsewhere a lot nicer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the feedback. Applied as requested.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, I think I'm happy with this. @weissi what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks very much. Looks good to me
@swift-server-bot test this please |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One question, otherwise LG
sorry @krzyzanowskim , this repo is set up with an formating requirements :|
mind running SwiftFormat on it? |
I am test it, got some error:
import Foundation
import AsyncHTTPClient
let httpClient = HTTPClient(eventLoopGroupProvider: .createNew)
let socketURL = URL(fileURLWithPath: "/var/run/docker.sock")
let req = try HTTPClient.Request(url: URL(string: "/_ping", relativeTo: socketURL)!, method: .GET)
let response = try httpClient.execute(request: req).wait()
print(response) OS: macOS |
@swift-server-bot add to whitelist |
@lou-lan try |
@weissi I got the same error message:
|
@lou-lan I updated example in description. Don't use |
@krzyzanowskim Success, thank you very much, very cool PR. |
Adds support for UNIX Domain Socket requests.
Usage: